X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C92FD2.CB8DCA07@onstor-exch02.onstor.net>; Thu, 16 Oct 2008 14:04:36 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C92FD2.CB8DCA07"
Content-class: urn:content-classes:message
Subject: RE: Functional Spec for Restarting Aborted Mirror Sessions
Date: Thu, 16 Oct 2008 14:04:35 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D8754@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D8733@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Functional Spec for Restarting Aborted Mirror Sessions
Thread-Index: Ackvwc2p16X2XnVpSBWREx63PQrjQQADPGaAAABkD3A=
References: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D86BA@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E0C0D8733@onstor-exch02.onstor.net>
From: "Deepak Veliath" <deepak.veliath@onstor.com>
To: "Jonathan Goldick" <jonathan.goldick@onstor.com>,
	"dl-Design Review" <dl-designreview@onstor.com>
Cc: "dl-Kegg" <dl-Kegg@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C92FD2.CB8DCA07
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Jonathan,
1.	Section 5, as you make clear, the key to restarting is to know
what the target has on disk, basically a checkpoint marker.  Since we
send blocks in order can we just periodically write out the last block
number know to have hit disk?  A super-block field would be easy.  While
an implementation note, this would avoid changing the cluster DB and
that is relevant here.  When all the blocks have been received we can
just set the number to the last block number in the file system so it
handles a lot of the cases you have mentioned.

We issue I/Os to read the blocks on the source in order.  But there
seems to be no guarantee the I/Os finish and return in that order.  We
send out blocks to the target as soon as they have been read.  On the
target again the I/O is issued as they come in over the RMC connection
but there seems to be no guarantee of ordering.  I realize our current
IO scheduler might guarantee some sort of ordering, but this could
change in the future.  The mirroring sub-system shouldn't expect it
works a certain way unless the IO scheduler exports a mechanism to
guarantee this ordering.
   =20
2.	Section 6, I'm not sure that the restart command adds a lot,
avoiding the creation of a new snapshot is the only clear addition over
mirror start and that doesn't seem worth creating a new command verb.

Since creating a new snapshot consumes some amount of space (and will
mean space can be allocated as the FS is modified), I felt a "restart"
only command would allow a previously aborted mirror to run through to
completion without potentially consuming space in the FS.
=20
3.	Section 6, mirror start MIRRORNAME [skiprestart] To date we have
not used whole words for command options in the shell, but instead use
things like -a, -b, etc.  Other than testing, why would a customer ever
want to skip a restart?  While a large transfer can happen at any point,
the real problem here is baseline transfers so if the target is garbage
in some way we can just start over by detecting that, rather than having
the administrator try to figure it out.  This also reduces the test
cases and the need to change the GUI or the CLI.=20

I see a lot of "force" options in the existing mirroring commands --
they were the basis for this choice.  I'll change it to "-s".  As to the
need for such an option, I felt a mechanism to bypass the whole restart
logic and being able to fall-back on to the traditional logic might be
desired by an administrator.  The baseline transfer has nothing to do
with this option and can be completed successfully with or without this
option.

Thank you,
veliath
=20

=20

=20

________________________________

From: Deepak Veliath=20
Sent: Thursday, October 16, 2008 12:03 PM
To: dl-Design Review
Subject: Functional Spec for Restarting Aborted Mirror Sessions

=20

\\mightydog\software\Kegg\Functional
Specs\RestartAbortedMirrorSessionsFuncSpec.doc
<file:///\\mightydog\software\Kegg\Functional%20Specs\RestartAbortedMirr
orSessionsFuncSpec.doc>=20


------_=_NextPart_001_01C92FD2.CB8DCA07
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: Functional Spec for Restarting Aborted Mirror =
Sessions</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">Hello Jonathan,</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 5, as you make =
clear, the key to restarting is to know what the target has on disk, =
basically a checkpoint marker.&nbsp; Since we send blocks in order can =
we just periodically write out the last block number know to have hit =
disk?&nbsp; A super-block field would be easy.&nbsp; While an =
implementation note, this would avoid changing the cluster DB and that =
is relevant here.&nbsp; When all the blocks have been received we can =
just set the number to the last block number in the file system so it =
handles a lot of the cases you have mentioned.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">We issue I/Os to read the blocks on the source in =
order.&nbsp; But there seems to be no guarantee the I/Os finish and =
return in that order.&nbsp; We send out blocks to the target as soon as =
they have been read.&nbsp; On the target again the I/O is issued as they =
come in over the RMC connection but there seems to be no guarantee of =
ordering.&nbsp; I realize our current IO scheduler might guarantee some =
sort of ordering, but this could change in the future.&nbsp; The =
mirroring sub-system shouldn't expect it works a certain way unless the =
IO scheduler exports a mechanism to guarantee this =
ordering.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;&nbsp;&nbsp; </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 6, I&#8217;m =
not sure that the restart command adds a lot, avoiding the creation of a =
new snapshot is the only clear addition over mirror start and that =
doesn&#8217;t seem worth creating a new command verb.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">Since creating a new snapshot consumes some amount of =
space (and will mean space can be allocated as the FS is modified), I =
felt a &quot;restart&quot; only command would allow a previously aborted =
mirror to run through to completion without potentially consuming space =
in the FS.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 6, mirror =
start MIRRORNAME [skiprestart] To date we have not used whole words for =
command options in the shell, but instead use things like &#8211;a, -b, =
etc.&nbsp; Other than testing, why would a customer ever want to skip a =
restart?&nbsp; While a large transfer can happen at any point, the real =
problem here is baseline transfers so if the target is garbage in some =
way we can just start over by detecting that, rather than having the =
administrator try to figure it out.&nbsp; This also reduces the test =
cases and the need to change the GUI or the CLI. </FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">I see a lot of &quot;force&quot; options in the =
existing mirroring commands -- they were the basis for this =
choice.&nbsp; I'll change it to &quot;-s&quot;.&nbsp; As to the need for =
such an option, I felt a mechanism to bypass the whole restart logic and =
being able to fall-back on to the traditional logic might be desired by =
an administrator.&nbsp; The baseline transfer has nothing to do with =
this option and can be completed successfully with or without this =
option.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">Thank you,</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">veliath</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">________________________________</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana">From: Deepak =
Veliath </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana">Sent: Thursday, =
October 16, 2008 12:03 PM</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana">To: dl-Design =
Review</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana">Subject: =
Functional Spec for Restarting Aborted Mirror Sessions</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">&nbsp;</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"></SPAN><A =
HREF=3D"file://\\mightydog\software\Kegg\Functional"><SPAN =
LANG=3D"en-us"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Verdana">\\mightydog\software\Kegg\Functional</FONT></U></SPAN></=
A><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana"> =
Specs\RestartAbortedMirrorSessionsFuncSpec.doc &lt;</FONT></SPAN><A =
HREF=3D"file:///\\mightydog\software\Kegg\Functional%20Specs\RestartAbort=
edMirrorSessionsFuncSpec.doc"><SPAN LANG=3D"en-us"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Verdana">file:///\\mightydog\software\Kegg\Functional%20Specs\Res=
tartAbortedMirrorSessionsFuncSpec.doc</FONT></U></SPAN></A><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Verdana">&gt; </FONT></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C92FD2.CB8DCA07--
